昨天看了三個「虛擬機」的機器服務架構，但其實昨天說的第三個架構(微服務時代)，仍然有不少隱性的問題：

• 浪費機器資源：
  每一台虛擬機都只放一個服務，對於連線數量小的服務可以開小規格的「虛擬機」資源。但是每次開一台虛擬機時,總是需要浪費一點資源提供給系統使用,且每一個服務本身都還需要保有備援機器，以防主要服務loading過高或者機器死亡，保持隨時可以救援狀態。

• 高成本：
  就算服務放置在「虛擬機」上，也不能任意在實體機身上大量建制「虛擬機」，畢竟「虛擬機」的資源仍然依附在實體機。所以當「虛擬機」數量過多時，也容易造成互相搶奪實體機器資源的情況。為了避免有這樣的情況發生，只好不斷的購買實體機器，避免「虛擬機」互搶資源。

• 管理不便：
  隨著公司成長，服務相對的也會越來越多。假設每個服務都有三台虛擬機(兩台在線上做負載平衡，一台作為備援機器)，當你有10個線上服務就會有30台虛擬機，但是剛剛只有提到線上服務機器，也許你會有「測試環境」的機器 + 「開發環境」的機器，這一些加一加10個服務可能就具備將近50台虛擬機器。

  而且當機器建制是由不同人經手時，難免會有一些些差異，這是最容易導致服務異常卻又難以找bug的問題。時常會有莫名其妙的特例問題發生，導致時常會聽到工程師在抱怨，環境不一致所以有些bug在測試環境無法順利測試。

• 版本升級不容易：
  你可能會遇到作業系統太過於老舊，不得不採用「先建後拆」的行為，此時新版作業系統的「虛擬機」器建制完成後，還需要考量code是否可以在新機器上正常服務。有可能會因為建制過程中某些套件版本過於老舊，或者資安問題不得不被迫升級版本，這時候就得更改code撰寫方式，為了配合新機器版本，本機套件跟作業系統也必須跟著升級，避免版本落差導致服務上至開發環境才發現異常，大多時間往往浪費在這時候。

當然還有更多的不便利性，但就光是以上幾點項目，加上管理的機器數量龐大，就足以每天都反覆處理類似的問題，雖然培養出打指令速度很快，但卻總是重複著相同行為，在工作上也漸漸失去熱忱。

因此接下來要介紹一個容器架構,但是此架構仍不是最好版本，可以思考一下以下架構解決的什麼問題，但是又有什麼問題尚未解決，答案明天揭曉。